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(57) Abstract 

A programmed computer system includes a set of development tools, each having a format used to store data and code files. The 
output data from a developmental tool is transformed into a generic format data which is saved in a repository. The repository also contains 
all output data, application components, and information as to the relationship between the entities and objects stored in the repository. 
Each too! employed during the development process puts information into the repository and takes information out of the repository. In this 
way, the system integrates the tools used in different parts of the development process by passing necessary information from one tool to 
another. Different tools are employed through each of the development stages, legacy integration, enterprise modeling, domain modeling, 
writing and editing of business logic, generating skeleton code, component building and wrapping and application deployment. 
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TOOL-INDEPENDENT APPLICATION DEVELOPMENT SYSTEM 



Field of the Invention 

The present invention relates in general to the field of automated systems 
5 for developing business applications. In particular, it relates to a tool-independent 
business application development system. 

Background of the Invention 

Business models are often utilized as a blueprint to depict how a company 

10 should operate and develop. Depending on the tool utilized, business models may 
be portrayed in different forms. One of the more common ways of representing 
business process models is by means of workflow diagrams. 

Business process models define business processes. Business processes 
describe activities that need to be performed within an organization. Examples of 

15 such activities may include processing purchase orders, payroll processing, or 
processing insurance claims. Actual software applications may be derived from 
business processes. These software applications, in conjunction with other software 
systems or team of humans, may accomplish a defined business process. 

Creation of business applications results in a need for a comprehensive 

20 environment that will support the entire business application development process. 
The process may start with the building of business models and progress to 
representing the business models as object models. The next step may be creating 
source code for the business logic, that is, the creation of methods for the business 
processes that represent details of how the business runs. For example, if the 

25 business process is the handling of purchase orders, one detail about how this 
process is accomplished may be that purchase orders over $1,000 must be 
approved by a manager. The development process may then proceed to building 
and wrapping components (reusable pieces of code), building applications from the 

l 
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components, and installing the new applications and components into the 
appropriate environments. 

The development process results in a further need to discover legacy 
systems, that is, existing applications, components, business processes, or other 
5 legacy systems, and integrate them into new business models which may in turn 
generate new business applications. The incorporation of existing legacy items into 
new applications will help preserve investments made in creating the legacy 
systems. 

The current technology does not adequately address these needs. Although 

10 there are tools which allow implementation of parts of the development process, no 
one single environment exists which supports the process from beginning to end. 

Another shortcoming of existing technology is the lack of ability to 
discover existing legacy items and incorporate them into new applications. 
Although there are tools that allow transformation of some legacy items into 

15 certain kinds of object models, these tools do not utilize the models to generate 
business applications. Furthermore, these tools are limited in their reverse 
engineering capabilities, and are also not generalized, meaning that they are able to 
transform only certain types of legacy items into object models. 

Another reason why existing technology does not adequately support 

20 legacy integration is because of the lack of a defined method to exchange relevant 
information between object models. Object models are often created to define the 
business objects used by various business processes. But because there is no 
defined method of exchanging information between object models that utilize 
different object modeling methods, objects appearing in one model cannot be 

25 utilized in another modeling tool. 

A further shortcoming of the current technology is the lack of tool and 
middleware independence in creating business applications. As an example of this 
shortcoming, if one tool is used to develop the business process model, one might 
be bound in the selection of the tools to create the application source code for the 
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model. The lack of tool independence is mainly due to the inability to exchange 
information between tools. 

Existing technology also does not allow specification and/or generation of 
source code for applications in a middleware-independent form. Thus, a 
5 component of an application built with one middleware cannot be automatically 
reused in a different environment with a different middleware. 

Summary of the Invention 

A programmed computer system according to the present invention attacks 
10 many of these problems. The programmed computer system includes a set of 
development tools, each having an input for receiving input data and each 
generating output data. The output data is transformed into a generic format data 
which is saved in a repository. 

The current invention uses the Unified Modeling Language ("UML") object 
15 model as the generic format of representing much of the output data. Once output 
data is transformed into a UML model, it is saved in the repository. The repository 
also contains all output data, application components, and information as to the 
relationship between the entities and objects stored in the repository. 

Each tool employed during the development process puts information into 
20 the repository and takes information out of the repository. In this way, the system 
integrates the tools used in different parts of the development process by passing 
necessary information from one tool to another. 

The development process supported by the system may generally start with 
legacy integration, enterprise modeling, or domain modeling. During legacy 
25 integration, third party tools are used to discover existing legacy systems. 
Discovered legacy items are then transformed into UML and may then be 
transformed to other object models or business process models. 
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The enterprise modeling stage and the domain modeling stage involve, 
respectively, the use of third party tools to create business process models and 
object models. These models are translated into UML and saved in the repository. 

The next step in the development process supported by the system is the 
5 writing and editing of business logic, that is, the methods for the business 
processes. The system allows developers to use the language of their choice in 
writing the methods. In addition, the system generates a skeleton code based on the 
information in the UML modeL This code is also saved in the repository. 

The methods are then built and wrapped into components in the component 
10 building phase. Built components are assembled into applications in the application 
assembly stage. Finally, applications are deployed to the appropriate environments 
in the application deployment stage. 

The system also allows a developer to perform various administrative tasks. 
These tasks may include adding, updating, or configuring new development tools. 
15 The user may also browse, search and install application components. The user 
may further catalog, browse and manage the objects in the repository. 
Brief Description of the Drawings 

FIG. 1 is a diagram illustrating the general flow of the development 
process. 

20 FIGS. 2a-2b are flow diagrams illustrating the execution of the shell 

process. 

FIG. 3 illustrates a sample screen presentation of the shell process. 
FIG. 4 illustrates a sample screen presentation for the tools process of the 
administrative phase. 

25 FIG. 5 illustrates a sample screen presentation for the discover process of 

the legacy integration phase. 

FIG. 6 illustrates a sample screen presentation for the transform process of 
the legacy integration phase. 
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FIG. 7 illustrates a sample screen presentation for the enterprise modeling 
process of the business modeling phase. 

FIG. 8 illustrates a sample screen presentation for the domain modeling 
process of the business modeling phase. 
5 FIG. 9 illustrates a sample screen presentation for the business logic phase. 

FIGS. lOa-lOc are flow charts illustrating the creation of a Visual Basic 
skeleton code during the business logic phase. 

FIGS, lla-llb illustrate sample screen presentations for the building and 
wrapping of components during the component building phase. 
10 FIG. 12 illustrates a sample screen presentation for the application 

assembly phase. 

FIG. 13 illustrates a sample screen presentation for the application 
deployment phase. 

FIG. 14 is a flow chart illustrating how Microsoft Transaction Server 
15 registers components into packages during the application deployment phase. 
Detailed Description 

The preferred embodiment of the present invention consists of a computer 
system having a user interface, a memory, a repository, and a set of third party 
tools. The computer system may be one of any variety of heterogeneous platforms, 
20 including PCs, Unix, Macintosh and Unisys systems. A user may select among 
various third party tools provided by the shell process to implement each stage of 
the application development. The shell process invokes the third party tools and 
coordinates the transfer of control between them. 

FIG. 1 shows the general flow of the application development process 
25 supported by the system. During legacy integration 26, legacy items are either 
discovered or transformed. Legacy items may include pre-existing applications, 
components, business processes, or other legacy systems. The discovered legacy 
items may then be transformed into business or object models, or into reusable 
components. 

5 
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During the enterprise modeling 28 stage, business process models are 
created and saved in the repository 20. 

Object models are created during the domain modeling 27 stage. Object 
models contain a variety of diagrams, including class diagrams. Object models 
5 may also contain use cases and some logic, such as state diagrams. 

Class diagrams describe the types of objects in a system and the various 
kinds of relationships which exist between them. Three main kinds of relationships 
are associations (e.g. a customer may rent a number of videos, the association 
being between a customer and videos), subtypes (e.g. a doctor is a kind of person), 
10 and aggregations (e.g. an engine is part of an automobile). A subtype relationship 
is between types; association and aggregation relationships are between objects. 

The next step in the development flow may be to write and edit business 
logic, that is, the methods for the business processes. This is accomplished in the 
business logic 29 stage. The methods are then built and wrapped into components 
15 in the component building phase 30. Built components are assembled into 
applications in the application assembly stage 31. Finally, applications are 
deployed to the appropriate environments in the application deployment 32 stage. 

Each tool employed during the development process puts information into a 
repository 20 and takes information out of the repository 20. In this way, the 
20 system integrates the tools used in different parts of the development process by 
passing necessary information from one tool to another. 

The repository 20 is, therefore, the central store of all information. AH of 
the entities and objects associated with the application under development, as well 
as relationships between these entities and objects, are stored in the repository 20. 
25 For example, the repository 20 may contain all of the business models, business 
logic application code, and binary components associated with an application. 

The repository 20 further includes tools for cataloging, browsing, and 
managing components that make up an application. Methods to support these 
services are disclosed in several patents and patent applications assigned to the 
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assignee of this application, including U.S. Patent 5,671,398 for METHOD FOR 
COLLAPSING A VERSION TREE WHICH DEPICTS A HISTORY OF 
SYSTEM DATA AND PROCESSES FOR AN ENTERPRISE; U.S. Patent 
5,644,764 for METHOD FOR SUPPORTING OBJECT MODELING IN A 

5 REPOSITORY; U.S. Patent 5,581,755 for METHOD FOR MAINTAINING A 
HISTORY OF SYSTEM DATA AND PROCESSES FOR AN ENTERPRISE; 
U.S. Patent 5,557,793 for IN AN OBJECT ORIENTED REPOSITORY, A 
METHOD FOR TREATING A GROUP OF OBJECTS AS A SINGLE OBJECT 
DURING EXECUTION OF AN OPERATION; pending application Ser. No. 

10 08/623,490, filed on March 28, 1996, for A METHOD FOR MAPPING TYPES IN 
A MODEL IN A OBJECT-ORIENTED REPOSITORY TO LANGUAGE 
CONSTRUCTS FOR A C BINDING FOR THE REPOSITORY; pending 
application Ser. No. 08/567,394, filed on December 1, 1995, for METHOD FOR 
GENERICALLY INVOKING OPERATIONS IN AN OBJECT ORIENTED 

15 REPOSITORY; pending application Ser. No. 08/549,352, filed on October 27, 
1995, for A METHOD FOR GENERATING OLE AUTOMATION AND IDL 
INTERFACES FROM METADATA INFORMATION; pending application Ser. 
No. 08/505,140, filed on July 25, 1995, for A METHOD FOR PROVIDING 
OBJECT DATABASE INDEPENDENCE IN A PROGRAM WRITTEN USING 

20 THE C++ PROGRAMING LANGUAGE; pending application Ser. No. 
08/506,647, filed on July 25, 1995, for A METHOD FOR GENERICALLY 
MANIPULATING PROPERTIES OF OBJECTS IN AN OBJECT ORIENTED 
REPOSITORY; pending application Ser. No. 08/489,313, filed on June 9, 1995, 
for A METHOD FOR LOCATING A VERSIONED OBJECT WITHIN A 

25 VERSION TREE DEPICTING A HISTORY OF SYSTEM DATA AND 
PROCESSES FOR AN ENTERPRISE; pending application Ser. No. 08/655,553, 
filed on May 30, 1996, for A METHOD FOR PACKING/UNPACKING C 
OPERATIONS TO/FROM RPC COMPATIBLE FORMAT USING THE RPC 
PROTOCOL TO OPERATE REMOTELY WITH AN OBJECT-ORIENTED 

7 
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REPOSITORY, each of which are hereby incorporated by reference as if set forth 
in full herein. 

The shell process allows users to enter the development process at any 
stage. As an example, the user may decide to skip the enterprise modeling 28 stage 

5 entirely and go straight into domain modeling 27. The system therefore naturally 
supports the highly iterative nature of application development. 

The system also supports legacy integration 26. This is achieved by 
allowing discovery and access to legacy items at run time, and transforming them 
into Rationale Unified Modeling Language (UML) object models. UML is a 

10 method for specifying, visualizing, and documenting the components (objects) of a 
system under development. Existing object-oriented methods all use different, and 
often conflicting, terminology to represent object-oriented concepts such as classes, 
associations, subtypes, and aggregations. UML is the result of an effort to create 
standardization in the various object-oriented methods. 

15 UML is used in the preferred embodiment of this invention as a neutral 

object model. Alternative embodiments for specific types of models may use future 
standard models, such as the Business Object Facility and Common Business 
Objects, which are currently under development by the Object Management Group, 
as well as the upcoming Workflow Coalition workflow model. 

20 Once legacy systems, object models, and business process models are 

transformed into UML, the resulting UML model is stored in the repository 20. 
The UML model may later be transformed into any other business process model 
or object model. The new business or object models may, in turn, become the basis 
for new applications. 

25 Tool independence is another feature supported by the system. The system 

allows tools used in one stage of the development process to transfer information 
to other tools used in other parts of the process by means of the repository 20. In 
other words, the repository 20 allows specific attributes to be attached to the 
applications under development in one part of the development flow, and those 

8 
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same attributes can be interrogated and used by other tools in other parts of the 
development flow. Developers may therefore freely choose among the most 
popular development tools for any stage of the development process without 
worrying about the coordination of these tools. 

5 The system also provides middleware independence. This is achieved by 

creating and maintaining source code for the various components of the 
applications in a middleware-independent form. Middleware may be described as 
software that provides connectivity between clients and servers. These may include 
connectivity to database, or messaging connectivity. 

10 The creation of middleware independent components allows developers to 

delay the need to decide which middleware is to be used until the components are 
built. This permits the same components to be used in different environments with 
different middlewares. 

FIGS. 2a-2b are flow diagrams illustrating the execution of the shell 

15 process. The process begins in the start bubble 40. From here, the user may chose 
to perform any part of the development process shown in FIG. I, including legacy 
integration 26, domain modeling 27, enterprise modeling 28, creation of business 
logic 29, component building 30, application assembly 31, and application 
deployment 32. 

20 Once the routine gets the user choice 45, an inquiry is made as to whether 

or not the choice is legacy integration (decision diamond 50). If the answer is YES, 
then a branch is taken to another inquiry as to whether or not to discover existing 
legacy items (decision diamond 55). An affirmative answer to this inquiry invokes 
the discover process 60. The discover process is explained below in conjunction 

25 with a more detailed description of FIG. 1 . 

If discovery is not chosen, a further inquiry is made as to whether or not the 
user chooses to transform discovered legacy items (decision diamond 70). The 
transform process 75 is invoked upon a YES answer. The transform process 75 is 

9 
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also explained below in conjunction with a more detailed description of FIG. 1. If 
the user does not choose to transform, the routine waits for a new user choice 77. 

If the user choice is not legacy integration, as depicted by the NO branch to 
decision diamond 50, a determination is made as to whether or not business 

5 modeling was selected (decision diamond 65). If the user chooses to do business 
modeling, an inquiry is made as to whether or not enterprise modeling was chosen 
(decision diamond 80). Enterprise modeling is the creation of business process 
models. If the answer is YES, then the enterprise modeling 28 process is invoked. 
This process is explained below in conjunction with a more detailed description of 

10 FIG. 1. 

If the answer to decision diamond 80 is NO, a further inquiry of whether or 
not domain modeling is to be done is made (decision diamond 90). Domain 
modeling is the creation of object models. The domain modeling 27 process is 
invoked upon an affirmative answer. This process is also explained below in 
15 conjunction with a more detailed description of FIG. 1. A negative answer causes 
the routine to wait for a new user choice 77. 

The user may also choose not to do business modeling, as depicted by the 
NO branch to decision diamond 65. In this case, an inquiry is made as to whether 
or not application construction was chosen (decision diamond 94). Under this 
20 selection, the user has a choice to write the source code for business logic 
applications, build components, assemble the components, or deploy assembled 
components. These processes are explained below in conjunction with a more 
detailed description of FIG. 1. 

If the user chooses to do application construction, as reflected by the YES 
25 branch to decision diamond 94, a further inquiry is made in decision diamond 96 as 
to whether or not the user has selected to do business logic. An affirmative answer 
to this inquiry invokes the business logic 29 process. 

A negative answer leads to the inquiry of whether or not the user wants to 
build components (decision diamond 98). The component building 30 process is 

10 
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invoked upon a YES answer. If the answer is NO, a further inquiry of whether or 
not the user wants to assemble the components is made (decision diamond 100). 
The YES branch invokes the application assembly 31 process. The NO branch 
results in a final inquiry of whether or not the user choice is to deploy assembled 

5 applications (decision diamond 102). If it is, the application deployment 32 process 
is invoked. If the user has made none of the choices available under application 
construction, as depicted by the NO branch from decision diamond 102, the routine 
waits for the user to make a new choice 77. 

Referring back to decision diamond 94, an answer of NO to the inquiry of 

10 whether application construction was chosen leads to a further inquiry of whether 
administration was chosen (decision diamond 104). Administrative functions are 
not part of the development flow. They may be invoked at any time to manage the 
development environment. Administrative functions include browsing, searching, 
and installing components, browsing repositories 20 (shown in FIG. 1), or 

1 5 installing and configuring third party tools. 

In decision diamond 104, then, if the user wants to perform administrative 
tasks, an inquiry is made as to whether or not the user has chosen to find 
components (decision diamond 106). If this is the case, the find components 
process is invoked 108 to allow the user to browse, search, and install components. 

20 Otherwise, a further inquiry is made in decision diamond 1 10 as to whether 

or not the user choice is to browse the repository 20. If the user wants to browse, 
the browse repository process 1 12 is invoked. The user may then view information 
in the underlying repository 20 by means of a generic repository browser. 

If the user does not want to browse, as reflected by the NO branch from 

25 decision diamond 1 10, a final inquiry is made as to whether or not a tools choice 
was made (decision diamond 1 14). A YES answer invokes the tools process 1 16 
which allows third party tools to be installed and configured. A NO answer causes 
the routine to wait for a new user choice 77. 

11 
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FIG. 3 is a sample screen presentation of the shell process. It consists of a 
legacy integration window 26a, business modeling window 35, application 
construction window 34, and administration window 33. 

The legacy integration window 26a contains two user options, a discover 
5 option 60a and a transform option 75a. These allow a user to discover legacy 
systems and transform them into UML, which may then be transformed to other 
object models and business process models. 

The business modeling window 35 allows the user to do the enterprise 
modeling 28 or domain modeling 27 steps illustrated in FIG. 1 . Thus, a user may 
10 select the enterprise button 28a or the domain button 27a to invoke the respective 
processes. 

The application construction window 34 presents the user with a business 
logic button 29a, build components button 30a, assemble button 31a, and a deploy 
button 32a. These buttons invoke, respectively, the business logic 29, component 
15 building 30, application assembly 31, and application deployment 32 processes 
shown in FIG. I. 

Under the administration window 33, users may perform several 
administrative tasks. They may browse, search, and install components by 
selecting the find components button 108a. They may also view information in the 

20 underlying repository 20 shown in FIG. 1 by selecting the browse repository button 
1 12a. Finally, users may also install and configure third party tools by selecting the 
tools button 1 16a. FIG. 4 shows the user interface screen upon a selection of the 
tools button 1 16a. The system allows users to add 118, remove 120, or configure 
122 different tools 124 to be used in different stages of the development process 

25 126 as well as other miscellaneous tools 128. 

With a better understanding of how the shell process operates, then, it is 
now appropriate to give more detailed descriptions of each of the major stages of 
the application development process. 

12 
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Referring back to FIG. I, the legacy integration 26 phase may consist of a 
discover process 60 and a transform process 75 (see FIG. 2a). The discover process 
60 invokes third party tools such as Microsoft CEDAR (which is a trademark of 
Microsoft Corp.) to get an inventory of the existing legacy environment. This 

5 existing environment may include transactions such as BEA Tuxedo (which is a 
trademark of BEA Systems, Inc.) or CICS (which is a registered trademark of IBM 
Corporation). The environment may also include relational database schema such 
as Oracle (which is a registered trademark of Oracle Corporation), SQL server, or 
DB2 (which is a trademark of IBM Corporation). The environment may further 

10 include source code, such as COBOL, RPG (report program generator), or PL/1, as 
well as libraries and their entry points. In addition, the environment may include 
object transaction server components such as ActiveX (which is registered 
trademark of Microsoft Corporation) or Java, or COTS (commodity off the shelf) 
applications, such as Excel (which is a registered trademark of Microsoft 

15 Corporation) or SAP (which is a trademark of SAS Institute, Inc.) Once the legacy 
items have been discovered, they are saved in the repository 20. 

FIG. 5 shows the user interface for the discover process 60 (see FIG. 2a). In 
this example, CICS transactions 130 are to be discovered using the third party tool 
Microsoft CEDAR 132. 

20 During the transform process 75 (see FIG 2a) of legacy integration 26 (see 

FIG 1), discovered legacy items are transformed into UML models. 
Transformation of legacy items into UML is described more in detail in the U.S. 
patent application submitted on the same day as this application, also assigned to 
the assignee of this application, entitled EXCHANGING INFORMATION 

25 BETWEEN DIFFERENT OBJECT MODELS AND THE UNIFIED LANGUAGE 
MODELING MODEL ('Transformation Algorithms"), which is incorporated by 
reference as if set forth in full herein. After transformation has been accomplished, 
the resulting UML model is saved in the repository 20. 

13 
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Once a discovered legacy item has been transformed into UML, it may then 
be transformed into other object or enterprise models by means of the Transform 
Algorithms. 

FIG. 6 shows the user interface for the transform process 75. In this 

5 example, Microsoft CEDAR 134 has been invoked to transform discovered legacy 
items 136 into a domain model. 

The development process shown in FIG. 1 may also involve business 
modeling. The business modeling phase entails the creation or modification of 
business process models by means of the enterprise modeling 28 process. Third 

10 party tools such as MooD (which is a trademark of MooD International, Ltd.), 
Designer/2000 (which is a registered trademark of Oracle Corporation), Adaptive 
Solutions (which is a registered trademark of Adaptive Solutions, Inc.), and Select 
Enterprise (which is a registered trademark of Select Software Tools, Inc.) may be 
utilized to build business process models. 

15 FIG. 7 shows the user interface for the enterprise modeling 28 process 

shown in FIG. 1 . Here, an existing business process model 140 has been selected to 
be modified by using MooD 142, an enterprise modeling tool. The domain button 
144 provides the user interface to transform a selected enterprise model into a 
domain model should the user choose to do so. 

20 The result of the enterprise modeling process 28 shown in FIG. 1 is saved 

in the repository 20. Two methods may be employed to accomplish this. Under one 
method, objects created by the enterprise modeling tool are transformed and saved 
directly as UML models by means of the Transformation Algorithms. Under 
another method, data from the modeling tool is exported into a database, and the 

25 database is saved into the repository. Data from the database is then imported into a 
UML model by means of the Transformation Algorithms. 

The next step of the development flow may be the creation of object 
models. Object models may be constructed or modified during the domain 
modeling 27 process from transformed legacy items or from enterprise models. 

14 



SUBSTITUTE SHEET (RULE 26) 



WO 99/15986 



PCT/US98/19527 



The system, moreover, allows reverse engineering of object models into enterprise 
models. 

Domain models are constructed by invoking third party tools under the 
control of the shell process. Examples of domain modeling tools are Rational Rose 
5 (which is a registered trademark of Rational), ERWin (which is a registered 
trademark of Logic Works, Inc.), and Designer/2000. It is noted that these tools 
may or may not utilize the UML method. The results of domain modeling are 
saved in the repository 20 by any of the two methods described for the enterprise 
modeling process 28. 

10 FIG. 8 is the user interface for the domain modeling 27 process shown in 

FIG. 1. Here, an existing domain model 146 has been selected to be modified by 
using Rational Rose 148, a domain modeling tool. The enterprise button 150 
provides the user interface to abstract a domain model into an enterprise model 
should the user choose to do so. 

15 Referring back to FIG. 1, the next step in the development flow may be the 

creation of business logic 29. During this stage, source code for the business logic 
(methods) are written and edited. The system allows developers to use the language 
of their choice in writing the methods, including Java, C++, Visual Basic (which is 
a registered trademark of Microsoft Corporation), or COBOL. 

20 In addition, skeleton code is generated based on the information in the 

UML model for the selected classes. A developer may build on the skeleton code 
to create the methods. Because the code is generated in a middleware "neutral" 
format, the developer is free to construct the methods independent of the final 
deployment environment. This allows the developer to concentrate only on the 

25 behavior of the method and not worry about access of the methods until component 
build time. 

FIG. 9 shows the user interface for the business logic 29 phase shown in 
FIG. 1 . Displayed in 152 are the classes in the selected model 154. In this example, 
Visual Basic 1 56 is chosen as the language to write the methods. 
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FIGS. 10a- 10c are flow diagrams illustrating the creation of a Visual Basic 
skeleton code during the business logic phase shown in FIG. 1. Skeleton codes for 
C++, COBOL, and Java may be produced in a similar way. 

The creation of the skeleton code begins with the start bubble 180. The user 
5 then decides which tool he wants to employ to write the methods. Depending on 
the tool chosen, a file with the appropriate extension name will be generated to 
build the classes for the selected component. 

Under decision diamond 185, an inquiry is made as to whether or not the 
user choice is Visual Basic. If it is, a ".vbp" and a ".els" file are generated 190. If 
10 the user choice is not Visual Basic, an inquiry is made to whether or not the choice 
is C++ (decision diamond 195). If the answer is YES, a ".cpp" file is generated 
200. 

If the user did not choose C++, a further inquiry is made as to whether or 
not the selection is COBOL (decision diamond 205). If it is, a ".cbl" file is 

15 generated 210. Otherwise, a final inquiry of whether or not the choice is JAVA is 
made (decision diamond 215). If JAVA is selected, a JAVA file is generated 220. 

Next, a Visual Basic skeleton code may be generated for all the classes in a 
selected component. This is achieved by first making an inquiry as to whether or 
not there are more classes in the selected component (decision diamond 225). If the 

20 answer is NO, the routine will exit 228. But if the answer is YES, it must be 
determined in decision diamond 230 whether or not Visual Basic was chosen. The 
NO branch to this inquiry results in a check to determine whether or not there are 
more classes in the component (decision diamond 225). The YES branch to this 
inquiry, signifying that the user chose Visual Basic as his tool, results in the 

25 generation of an appropriate class header 235. 

The next stage of the routine involves performing certain steps for all the 
members of the class. Therefore, an inquiry is made in decision diamond 240 as to 
whether or not there are more members in the class. If the answer is YES, the 
visibility of the member is determined as being either public or private 245. 

16 
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A member may be a method or an attribute. If the member is a method, as 
depicted by the YES branch to decision diamond 250, the following steps are 
invoked. First, all the parameters of the method are checked to determine if the 
method is a fiinction. If the method is a function, the return type is determined. 

5 Thus, an inquiry is made as to whether or not there are more parameters in the 
method (decision diamond 255). If the answer is YES, a determination must be 
made in decision diamond 260 as to whether or not the parameter is a return kind. 
If not, the other parameters of the method are checked. If the parameter is a return 
kind, then the method is a fiinction 265 and the return type is determined 270. 

10 Second, after all the parameters in the method have been checked, as 

reflected by the NO branch to decision diamond 255, an inquiry is made in 
decision diamond 275 as to whether or not the method is a subroutine. If the 
answer is YES, a determination is made as to whether or not the method is of a 
PROPERTY JLET (decision diamond 280). But if the answer is NO, a 

15 determination is made as to whether or not the method is of a PROPERTY_GET 
(decision diamond 285). 

Third, for each parameter in the method, the routine determines the 
parameter name and type information. This is accomplished by inquiring in 
decision diamond 290 whether or not there are more parameters in the method. If 

20 so, the parameter name and type information are generated 295. 
Fourth, the method signature is produced 300. 

Finally, an inquiry is made as to whether or not the stereotype of the 
method is a transaction (decision diamond 305). If it is a transaction, then a 
transaction neutral body is produced for signature 310. Otherwise, just the body is 
25 produced for signature 340. The routine then reverts back to decision diamond 240 
to determine whether or not there are more members in the class. 

Referring back to decision diamond 250, if the member is not a method, as 
depicted by the NO branch, then an inquiry is made as to whether or not the 
member is an attribute (decision diamond 315). If the answer is YES, then the 
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attribute name and type are obtained 320. Next, an inquiry is made as to whether or 
not the attribute is a constant (decision diamond 325). If it is a constant, as shown 
by the YES branch, then the constant definition is produced 330. Otherwise, the 
attribute is not a constant and the attribute definition is produced 335. The routine 
5 then reverts back to decision diamond 240 to determine whether or not there are 
more members in the class. 

When there are no more members in the class, as depicted by the NO 
branch to decision diamond 240, and there are no more classes in the component, 
as depicted by the NO branch in decision diamond 225, the routine will exit 228. 

10 The resulting component code can be versioned using off-the-shelf code 

management tools such as Intersolv PVCS (which is a trademark of Intersolv, Inc.) 
or Microsoft SourceSafe (which is a registered trademark of Microsoft 
Corporation). The resulting files are then kept in the repository 20 (see FIG. 1). 

The next step in the development flow shown in FIG. 1 may be the building 

15 and wrapping of components. This is accomplished during the component building 
30 phase. It is the building and wrapping of components which makes them 
available for use by applications and other components. During this phase, selected 
components from a selected model are built using third party tools such as MS 
Development Studio (which is a trademark of Microsoft Corp.), Visual Basic, 

20 Micro Focus COBOL or Visual Age for Java (which is a trademark of IBM 
Corporation). 

The key concept in building and wrapping components is the separation of 
component behavior from the environment it runs in. This allows components to be 
deployed in different environments. The environment may include middleware, the 
25 threading model, object caching, integration with systems management, hooks to 
make the component testable and tunable, and security. 

Middleware decisions may, but need not be made during the component 
building 30 phase. Middleware options include transactional middleware, such as 
Microsoft Transactional Server (which is a trademark of Microsoft Corp.) or BEA 
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Tuxedo; messaging middleware, such as IBM MQ (which is trademark of IBM 
Corporation) or Microsoft MSMQ (which is a trademark of Microsoft); procedural 
middleware, such as DCOM (which is a trademark of Microsoft Corp.) or CORBA 
(which is a trademark of Object Management Group, Inc.); or HTML and Internet 
5 Server based middleware, such as Microsoft (which is a registered trademark of 
Microsoft Corp.) or Netscape (which is a registered trademark of Netscape 
Communications Corporation). 

The system is capable of displaying middleware "hints" that are available 
from the UML model. For example, if a class is transactional, this information is 
10 displayed by the system, allowing the user to choose a transactional middleware 
when middleware decisions must be made. 

If, a transactional middleware is chosen, the transactional^ neutral code is 
parsed and coded to handle transactions in the selected transactional middleware. 
The neutral code is saved in the repository 20 and the same code can be deployed 
1 5 into a different transactional middleware. 

If no middleware decision is made, the logic of the built component can be 
tested without requiring it to be part of the overall infrastructure of the entire 
application. 

The components that are built and the components that the built 
20 components call are registered in the repository 20. A linked list of which 
components are consumed or are consumed by other components is also 
maintained in the repository 20. 

FIGS. 1 la- 1 lb show the user interface screens for the component building 
phase. FIG. 1 la illustrates the user's choice to build a component with a Customer 
25 class 341 selected from the Books Works model 342. In FIG. lib, middleware 
hints 343 for the selected class 341a is displayed. Shown here is the hint that the 
selected class 341a, the Customer class, is transactional and that transactional 
middleware such as Microsoft Transaction Server or BEA Tuxedo may be 
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designated as the middleware. The user is also given a choice between ActiveX and 
JAVA BEAN (which is a trademark of Sun Microsystems, Inc.) 

Referring back to FIG. 1, applications are constructed from the components 
built during the component building phase 30. The application assembly 3 1 process 

5 consists primarily of building the logic and structures to link the components 
together. Assembling applications this way allows a variety of applications to be 
constructed using the same basic components. FIG. 12 is the user interface screen 
showing the application assembly process. 

Third party tools such as Microsoft InterDev (which is a trademark of 

10 Microsoft Corp.), Microsoft Front Page (which is a trademark of Microsoft Corp.), 
Forte (which is a registered trademark of Forte Software, Inc.), Borland Delphi 
(which is a trademark of Borland International, Inc.), Microsoft Visual Basic, or 
Power Builder (which is a trademark of Sybase, Inc.) may be used to assemble 
previously built components into applications. Application components and the 

15 components that these application components call are registered in the repository 
20. A linked list of which components are consumed or are consumed by other 
components is also maintained in the repository 20. 

The development process shown in FIG. 1 will generally end in the 
application deployment 32 stage. Deployment takes built applications and installs 

20 them in the appropriate environments. FIG. 13 shows the user interface for the 
application deployment 32 process. 

The deployment process also involves verifying that the necessary support 
software is installed at the right level, physically copying the binary code, and 
registering the applications in the enterprise directory service. 

25 Deployment information is obtained from third party tools such as 

CA-Unicenter TNG (which is a registered trademark of Computer Associates 
International, Inc.) or Microsoft System Management Server (which is a trademark 
of Microsoft Corp.) These tools further provide utilities that may be employed by a 
wizard to deploy the software. 
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Before applications are deployed, however, the various components of the 
applications are wrapped as packages. The packaged components are then 
deployed to the appropriate environments. The packaged components are 
instrumented for systems and application management by appropriate deployment 

5 "hints" and management "hints." 

FIG. 14 is a flow chart illustrating how Microsoft Transaction Server 
registers components into packages. The routine begins at the start bubble 345. 
From there, an inquiry is made as to whether or not a new package is to be created 
(decision diamond 350). If the package is new, as depicted by the YES branch, 

10 then a further inquiry is made as to whether or not the package name is a duplicate 
(decision diamond 355). A duplicate package name results in an error message 360 
and exit from the routine 390. 

If the package name is not a duplicate, as depicted by the NO branch to 
decision diamond 355, then a new package is created 365 and components are 

15 installed into the package 370. 

Referring back to decision diamond 350, if a new package is not to be 
created, then a determination is made as to whether or not an existing package is to 
be reloaded (decision diamond 375). If the answer is YES, all components from the 
existing package are removed 380 and new components are installed 385. 

20 Otherwise, if an existing package is not to be reloaded the routine will exit 390. 

Although the invention has been described with reference to a specific 
embodiment, this description is not meant to be construed in a limiting sense. 
Various modifications of the disclosed embodiment as well as alternative 
embodiments of the invention will become apparent to one skilled in the art upon 

25 reference to the description of the invention. It is therefore contemplated that the 
appended claims will cover any such modifications of embodiments that fall within 
the true scope of the invention. 
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What is Claimed is: 



1 1. A system for developing computer applications using a set of 

2 development tools, each having an input for receiving input data and each 

3 generating output data, the system comprising: 

4 for each of a plurality of the set of development tools, 

5 means for translating the output data of the development tool 

6 into generic format data; and 

7 a repository that stores the generic format data; and 

8 for each of a plurality of the set of development tools, 

9 means for translating the generic format data from 

10 the repository into input data and supplying the input data to the input of one or 

1 1 more of the development tools. 
12 

1 2. The system of claim 1 wherein the repository further stores the 

2 output data and the relationship between the output data and the generic format 

3 data 
4 

1 3. The system of claim 1 wherein the generic format of the output data 

2 stored in the repository further comprises representations of objects and the 

3 repository further comprises means for storing the representations of such objects 

4 and relationships between such objects. 
5 

1 4. The system of claim 3 wherein the repository further comprises 

2 tools for cataloging, browsing and managing the representations of such objects 

3 and relationships between such objects. 
4 

1 5. The system of claim 1 wherein the repository further stores 

2 application components and the repository further comprises tools for browsing, 

3 searching and installing the application components. 
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1 6. The system of claim 1 further comprising means for adding a new 

2 development tool to the system comprising means for updating and configuring the 

3 means for translating the output data and the means for translating the generic 

4 format data for the new development tool. 
5 

1 7. The system of claim 1 wherein one of the development tools is a 

2 legacy discovery tool. 
3 

1 8. The system of claim 7 wherein, for the legacy discovery tool, the 

2 means for translating the output data comprises means for translating the output 

3 data into Unified Modeling Language format. 

1 9. The system of claim 1 wherein one of the development tools is a 

2 business process modeling tool. 
3 

1 10. The system of claim 9 wherein, for the business process modeling 

2 tool, the means for translating the output data comprises means for translating the 

3 output data into Unified Modeling Language format. 
4 

1 1 1. The system of claim 1 wherein one of the development tools is a 

2 domain modeling tool. 
3 

1 12. The system of claim 1 1 wherein, for the domain, modeling tool, the 

2 means for translating the output data comprises means for translating the output 

3 data into Unified Modeling Language format 
4 

1 13. The system of claim 1 further comprising means for generating 

2 skeleton code from the data stored in the repository. 
3 
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1 14. The system of claim 13 further comprising means for storing 

2 representations of the generated skeleton code in the repository. 
3 

1 15. The system of claim 1 wherein one of the development tools is a 

2 component building tool. 

1 16. The system of claim 1 wherein one of the development tools is an 

2 application building tool. 

3 

1 17. The system of claim 1 wherein one of the development tools is an 

2 application deployment tool. 
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